1. Field of the Invention
The present invention relates to a method and apparatus for reducing the memory requirements of software loads, in particular, a method and apparatus for the identification and removal of unused procedures and use of procedure shells to maintain the integrity of the procedure table during computer software loadbuilding time.
2. Description of the Problem Solved
In the telephonic industry, consumer demand for additional telephonic functionality increases the software load on the telephonic computer hardware designated to execute such loads. The increase in software load decreases the remaining life of the computer hardware. At some point, the computer hardware cannot handle additional functionality and a telephonic vendor has to stop delivery of features, upgrade the hardware, or reduce the load while maintaining increased functionality. Thus, there is a need to provide computer software for increasing the software load capacity on telephonic computer hardware. Such computer software should extend the life of telephone switch hardware by reducing the hardware memory requirement of telephone switch software, and also reduce the memory requirement of computer software of Extended Peripheral Modules (XPMs). XPMS are the telephony hardware that implement many of the various telephony computer software applications. For example, XPMs can collect digits, link different telecompanies and private networks, track data, manage communication between trunks, manage residential telephone lines, and control telephone tone generation, as well as handling such software driven applications as speed dialing. The present invention relates to computer software and a method for preserving computer memory by recognizing those computer program procedures not used in a particular software load and then removing them during loadbuilding.
The term "loadbuilding" is used herein to refer to the compiling and linking of computer code to produce the final software load. The term "software load" is used herein to refer to the final computer software that is executed by computer hardware for a particular application. A software load is developed from high-level computer language referred to as source code. The source code file of a software load is compiled by one of a number of compilers as are well known in the field to produce an object code file. Object code files are linked together by a linker to produce the software load, which can then be executed by the machine (computer hardware such as a XPM or PC). In particular applications, the source code, for example, written in Pascal, is compiled into an intermediate language identified as pcode. Xysco.TM., a software building tool developed by Nortel, takes the link code file and converts time critical sections from pcode to object code.
Software loads are comprised of modules. A module is a portion of a software load that carries out a specific function and may be used alone or with other modules. Within each module are self-contained blocks of software called procedures. If a particular application or load requires a procedure in a particular module, the linker pulls in the entire module, along with all procedures contained in the module. By way of example, FIG. 1 illustrates three modules A, B, and C. Each module contains three procedures: ap1, ap2, and ap3; bp1, bp2, and bp3; and cp1, cp2, and cp3, respectively. It is understood that modules can contain substantially more than three procedures.
Referring again to FIG. 1, if software load L1 requires ap1, bp2, and cp2, a compiler would first compile source code to object code and then a linker or other suitable software building tool would link together the modules containing these procedures into software load L1, i.e., would place into L1 each module A, B, and C and all procedures contained therein. Similarly, software load L2 requires ap2, bp3, and cp3. Again, during loadbuilding, the linker would link together the modules containing these procedures to form software load L2, i.e., would place into L2 each module A, B, and C and all procedures contained therein. Despite the different procedures required by software loads L1 and L2 and despite each not needing all of the procedures contained in modules A, B, and C, during loadbuilding, the traditional linker links together all three modules A, B, and C, and all procedures contained therein to form software loads L1 and L2. Clearly, when building software loads, presently used linkers will create loads that take up valuable computer hardware memory for procedures that are not implemented when the load is executed. (The computer memory used by a particular software load is referred to herein as a "memory footprint.")
The present invention recognizes that it would be advantageous to, during this software loadbuilding process, for compilers, linkers, and other software loadbuilding tools such as Xsyco.TM. to identify the procedures that are not used in the final software load and remove them, thereby creating a smaller computer memory footprint having the same functionality as the software load built using traditional compilers, linkers, and other software building tools.
With the foregoing in mind, it becomes a general object of the present invention to extend the service life of hardware by removing unused procedures from a software load resident on such hardware.
It is another object of the present invention to recognize unused procedures contained within modules used to build particular software loads.
It is a further object of the present invention to define all procedures, all required procedures, and entry points within each module.
It is yet another object of the invention to remove unused procedures during the loadbuilding process.
It is a further object of the invention to use procedure shells to maintain the integrity of each linked segment and corresponding procedure directories.
It is an object of the invention to use a placeholder, or tombstone, in the procedure directory to maintain the integrity of the procedure directory.